MPLS Unicast L3VPN
Published: 2022-01-10
A routed virtual private network. This is mostly sold by Service Providers, allowing customers to build a private WAN that interconnects their different sites. The main benefit for the customer is that they can use the service provider backbone infrastructure instead of building their own, effectively outsourcing the WAN maintenance, monitoring and troubleshooting to the SP.
With modern technologies like IPsec + SDWAN and cheaper internet ciruits, many thought that MPLS L3VPN would soon be deprecated; MPLS L3VPN circuits often perform better because of the full infrastructure belonging to the same service provider. A VPN circuit can often provide lower latency and allow for traffic prioritization using QoS, whereas an internet circuit is always best-effort.
Anyway, this post is not about why you would choose to use it but rather how to configure it in your service provider network.
Network topology and BGP VPN Label
Let's use the following topology as an example. We have two customers, RED and BLUE, each in their own VRF, separating their traffic and keeping their respective networks private. Each CE router represent a customer site, except for CE71 and CE81 that belong to the same site. Every site has one or multiple subnets advertised by the CE via eBGP to the nearest PE.
The VPNv4 magic happens when the CE-routes are advertised from PE to PE, where a MPLS label is added to the advertised route. This label is pushed by the ingress PE and examined by the egress PE to map the packet to the correct VRF or CE next-hop. In either case, we will call it the VPN label.
CE-PE IP Packet: PE-PE MPLS Packet:
+-----------------+ +-----------------+
| Ethernet Header | | Ethernet Header |
+-----------------+ +-----------------+
| IPv4 Header | | MPLS Header | <-- LDP Transport label
+-----------------+ +-----------------+
| Payload | | MPLS Header | <-- BGP VPN label
+-----------------+ +-----------------+
| IPv4 Header |
+-----------------+
| Payload |
+-----------------+
The transport label allows us to build the BGP-free core where the P-routers only need to know how to forward traffic between PEs. Customers may freely use overlapping IP-ranges inside their VPNs because the P-routers are forwarding based on a label and not based on the destination IP-address.
When CE51 sends traffic to CE71, PE5 pushes two labels to the packet; the inside VPN label that was advertised by PE7 and the transport label that tells P1 and P3 to forward the packet to PE7. PE7 reads and pops the VPN label before forwarding the IP packet to CE71.
RT and RT
This section will look at the different BGP VPNv4 attributes and how they are used to build different topologies.
Route Distinguisher
The RD is a locally significant value that separate identical routes by prepending the route distinguisher to the advertised prefix, 10.0.0.0/8 in the examples below. The RD can be written in two formats, ASN or RID:
-
AS-number:VRF-ID
The first 32-bit integer uses the local BGP AS-number, in this example 65000:1 and 65000:2. The second 32-bit integer identifies the VRF-ID. The two routes are identical but still different because the VRF-IDs in the route distinguisher have different values:- 65000:1:10.0.0.0/8
- 65000:2:10.0.0.0/8
-
Router-ID:VRF-ID
The first 32-bit integer uses the local router ID, in this example 10.0.0.5:123 and 10.0.0.6:123. The second 32-bit integer identifies the VRF-ID. This time the route and VRF-ID is identical so this time the Router-ID is the tie-breaking distinguisher:- 10.0.0.5:123:10.0.0.0/8
- 10.0.0.6:123:10.0.0.0/8
Both formats have their pros and cons. The ASN format scale better as routes with the same VRF-ID are considered identical meaning the RR will select one best route to forward. The drawback is slower convergence as the active route has to be withdrawn before the next-best route can be advertised. Another drawback is path-hiding depending on the RR location in the network.
The RID format allows for ECMP and faster convergence because identical routes with the same VRF-ID will be advertised thanks to the route-dstinguisher being different. With two active routes, withdrawing one has less impact. The drawback is that more routes are advertised and installed requiring more memory on the PEs.
Let's assume CE61 is advertising 10.0.0.0/8 to PE5 and PE6 and they advertise the route to the RRs with the 65000:1 RD prepended. The two routes are identical so the RR BGP bestpath algorithm prefer the PE5 route because of the lower Router-ID. This is a problem for PE8 as it has a shorter path to CE61 via PE6 that was never advertised, meaning PE8 will send its traffic to PE5 instead. If PE5 and PE6 advertised with RD 10.0.0.5:1 and 10.0.0.6:1, respectively, then PE8 would receive both routes and select the shorter PE6 path.
Route Target
This is a BGP extended community that is configured per VRF by the administrator and sent as an attribute with every advertised prefix. Like the RD, the format is <32-bit integer>:<32-bit integer>. Most often, the AS is assigned as the first integer and the VRF-ID as the second integer. In a simple deployment, the RD and RT often end up being the same value, for example 65000:123.
Whenever a route is received, the route route target is matched against the local PE VRF route-targets, and if a match is found, the route is imported into that VRF. Any received route without a matching VRF is discarded, saving space in the RIB.
Importing and exporting the same route-target builds a full-mesh between the PEs in the VPN. By using separate imports and exports you can build a hub-spoke topology. Let's look at the blue VRF and say CE52 is the Hub site. PE5 advertises its CE-routes with the 65000:52 route-target and imports any route with the route-target 65000:2. All other PEs advertise their CE routes with the 65000:2 route-target and import routes with the 65000:52 route-target. This means that PE6, PE7 and PE8 only learn the CE52-prefixes while PE5 learn all the CE-prefixes. The end result is a topology where the non-CE52 routers are only able to communicate with CE52.
By using multiple route-targets you can create vrf route-leaking, allowing devices in two VRFs to communicate, assuming there is no IP range overlap. One use case is building a MGMT-VRF that allows a jumphost to access all CEs regardless of what VRF the CE is in.
VPN label
Packets from CE71 to CE51 arriving on PE7 will have the BGP VPNv4 label 299952 and LDP transport label 299904 pushed and then forwarded to P3. The transport label will be swapped by P3 and popped by P1, exposing the VPN label when the packet arrives at PE5.
Label modes
The default behavior label assignment mode in IOS XR is per-prefix, meaning the PE assigns a unique label to each VPNv4 route when advertised to the RR. This allows the egress PE to skip the routing lookup step when forwarding as the label forwarding instruction includes the outgoing interface and next-hop IP address.
Changing the behavior to label mode per-vrf, the PE assigns a single label for the VRF and advertises all routes with this label. This means that when the egress PE receives the labeled traffic it first reads the VPN label to identify the VRF then performs a routing lookup on the IP header to find the outgoing interface and next-hop IP address.
Per-prefix is faster because it allows the PE to skip the routing lookup step but requires more labels and is therefore less scalable than per-vrf label mode.
A third mode, per-ce, exist that is a middle-ground between per-prefix and per-vrf. Each CE next-hop receives its own label. This is beneficial if 100 routes have the same next-hop address as only one label is generated instead of 100. It is also more efficient than per-vrf as the PE can skip the routing lookup step. This is the default behavior on Junos.
IOS XR label modes:
- Per-prefix (default)
- Per-VRF
- Per-CE
Junos label modes:
- Per-CE (default)
- Per-VRF
Initial MPLS configuration
The initial OSPF + LDP configuration is shown below. We have not yet configured iBGP or the customer VRFs. Linknet format is 10.X.Y.Z/24:
- X = Lower node ID
- Y = Higher node ID
- Z = Local node ID
- 10.1.2.1/24 = P1 address on the P1-P2 linknet
- 10.1.3.3/24 = P3 address on the P1-P3 linknet
set interfaces ge-0/0/0 unit 0 family inet address 10.1.3.1/24
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces ge-0/0/1 unit 0 family inet address 10.1.2.1/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 10.1.5.1/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces ge-0/0/3 unit 0 family inet address 10.1.11.1/24
set interfaces lo0 unit 0 family inet address 10.0.0.1/32
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 ldp-synchronization
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 ldp-synchronization
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 ldp-synchronization
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface lo0.0 metric 1
set protocols ldp interface ge-0/0/0.0
set protocols ldp interface ge-0/0/1.0
set protocols ldp interface ge-0/0/2.0
set protocols mpls icmp-tunneling
set protocols mpls interface ge-0/0/0.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
interface Loopback0
ipv4 address 10.0.0.2 255.255.255.255
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.2.4.2 255.255.255.0
!
interface GigabitEthernet0/0/0/1
ipv4 address 10.1.2.2 255.255.255.0
!
interface GigabitEthernet0/0/0/2
ipv4 address 10.2.6.2 255.255.255.0
!
interface GigabitEthernet0/0/0/3
ipv4 address 10.2.11.2 255.255.255.0
!
router ospf 1
address-family ipv4
area 0
interface Loopback0
!
interface GigabitEthernet0/0/0/0
network point-to-point
mpls ldp sync
!
interface GigabitEthernet0/0/0/1
network point-to-point
mpls ldp sync
!
interface GigabitEthernet0/0/0/2
network point-to-point
mpls ldp sync
!
interface GigabitEthernet0/0/0/3
network point-to-point
!
mpls ldp
address-family ipv4
label
local
allocate for host-routes
!
interface GigabitEthernet0/0/0/0
!
interface GigabitEthernet0/0/0/1
!
interface GigabitEthernet0/0/0/2
set interfaces ge-0/0/0 unit 0 family inet address 10.1.3.3/24
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces ge-0/0/1 unit 0 family inet address 10.3.4.3/24
set interfaces ge-0/0/1 unit 0 family mpls
set interfaces ge-0/0/2 unit 0 family inet address 10.3.7.3/24
set interfaces ge-0/0/2 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.0.0.3/24
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 ldp-synchronization
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 ldp-synchronization
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 ldp-synchronization
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface lo0.0 metric 1
set protocols ldp interface ge-0/0/0.0
set protocols ldp interface ge-0/0/1.0
set protocols ldp interface ge-0/0/2.0
set protocols mpls icmp-tunneling
set protocols mpls interface ge-0/0/0.0
set protocols mpls interface ge-0/0/1.0
set protocols mpls interface ge-0/0/2.0
interface Loopback0
ipv4 address 10.0.0.4 255.255.255.255
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.2.4.4 255.255.255.0
!
interface GigabitEthernet0/0/0/1
ipv4 address 10.3.4.4 255.255.255.0
!
interface GigabitEthernet0/0/0/2
ipv4 address 10.4.8.4 255.255.255.0
!
interface GigabitEthernet0/0/0/3
ipv4 address 10.4.12.4 255.255.255.0
!
router ospf 1
address-family ipv4
area 0
interface Loopback0
!
interface GigabitEthernet0/0/0/0
network point-to-point
mpls ldp sync
!
interface GigabitEthernet0/0/0/1
network point-to-point
mpls ldp sync
!
interface GigabitEthernet0/0/0/2
network point-to-point
mpls ldp sync
!
interface GigabitEthernet0/0/0/3
network point-to-point
!
mpls ldp
address-family ipv4
label
local
allocate for host-routes
!
interface GigabitEthernet0/0/0/0
!
interface GigabitEthernet0/0/0/1
!
interface GigabitEthernet0/0/0/2
set interfaces ge-0/0/0 unit 0 family inet address 10.1.5.5/24
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.0.0.5/32
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface lo0.0 metric 1
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 ldp-synchronization
set protocols ldp interface ge-0/0/0.0
set protocols mpls interface ge-0/0/0.0
set routing-options autonomous-system 65000
interface Loopback0
ipv4 address 10.0.0.6 255.255.255.255
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.2.6.6 255.255.255.0
!
router ospf 1
mpls ldp sync
address-family ipv4
area 0
interface Loopback0
!
interface GigabitEthernet0/0/0/0
network point-to-point
!
mpls ldp
address-family ipv4
label
local
allocate for host-routes
!
interface GigabitEthernet0/0/0/0
end
set interfaces ge-0/0/0 unit 0 family inet address 10.3.7.7/24
set interfaces ge-0/0/0 unit 0 family mpls
set interfaces lo0 unit 0 family inet address 10.0.0.7/32
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface lo0.0 metric 1
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 ldp-synchronization
set protocols ldp interface ge-0/0/0.0
set protocols mpls interface ge-0/0/0.0
set routing-options autonomous-system 65000
interface Loopback0
ipv4 address 10.0.0.8 255.255.255.255
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.4.8.8 255.255.255.0
!
router ospf 1
mpls ldp sync
address-family ipv4
area 0
interface Loopback0
!
interface GigabitEthernet0/0/0/0
network point-to-point
!
mpls ldp
address-family ipv4
label
local
allocate for host-routes
!
interface GigabitEthernet0/0/0/0
end
set interfaces ge-0/0/0 unit 0 family inet address 10.1.11.11/24
set interfaces ge-0/0/1 unit 0 family inet address 10.2.11.11/24
set interfaces lo0 unit 0 family inet address 10.0.0.11/32
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 metric 100
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 metric 100
interface Loopback0
ipv4 address 10.0.0.12 255.255.255.255
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.3.12.12 255.255.255.0
!
interface GigabitEthernet0/0/0/1
ipv4 address 10.4.12.12 255.255.255.0
!
router ospf 1
address-family ipv4
area 0
interface Loopback0
!
interface GigabitEthernet0/0/0/0
cost 100
network point-to-point
!
interface GigabitEthernet0/0/0/1
cost 100
network point-to-point
This configuration allows for basic MPLS connectivity through our SP network core. We have not enabled LDP towards the RRs because they will not be forwarding traffic anyway. To make sure the RR links are less attractive, we increased their metric to 100.
Configuring BGP VPNv4
We enable the VPNv4 address family on our PEs and RRs. The PEs connect to both RRs for redundancy.
set protocols bgp group RR local-address 10.0.0.5
set protocols bgp group RR family inet-vpn unicast
set protocols bgp group RR peer-as 65000
set protocols bgp group RR neighbor 10.0.0.11
set protocols bgp group RR neighbor 10.0.0.12
set routing-options autonomous-system 65000
router bgp 65000
address-family vpnv4 unicast
!
neighbor-group RR
remote-as 65000
update-source Loopback0
address-family vpnv4 unicast
!
neighbor 10.0.0.11
use neighbor-group RR
!
neighbor 10.0.0.12
use neighbor-group RR
set protocols bgp group RR local-address 10.0.0.7
set protocols bgp group RR family inet-vpn unicast
set protocols bgp group RR peer-as 65000
set protocols bgp group RR neighbor 10.0.0.11
set protocols bgp group RR neighbor 10.0.0.12
set routing-options autonomous-system 65000
set routing-options autonomous-system 65000
set protocols bgp group PE peer-as 65000
set protocols bgp group PE local-address 10.0.0.11
set protocols bgp group PE family inet-vpn unicast
set protocols bgp group PE cluster 10.0.0.11
set protocols bgp group PE neighbor 10.0.0.5
set protocols bgp group PE neighbor 10.0.0.6
set protocols bgp group PE neighbor 10.0.0.7
set protocols bgp group PE neighbor 10.0.0.8
set routing-options rib inet.3 static route 0.0.0.0/0 discard
router bgp 65000
address-family vpnv4 unicast
!
neighbor-group PE
remote-as 65000
update-source Loopback0
address-family vpnv4 unicast
route-reflector-client
!
neighbor 10.0.0.5
use neighbor-group PE
!
neighbor 10.0.0.6
use neighbor-group PE
!
neighbor 10.0.0.7
use neighbor-group PE
!
neighbor 10.0.0.8
use neighbor-group PE
The PE7 configuration is identical to PE5 apart from the local-address that should be changed from 10.0.0.5 to 10.0.0.7. With this configuration enabled, our PE routers may exchange VPNv4 routes. No such route has been generated yet, let's fix that by configuring a VRF!
Configuring the RED VRF
A VRF is a virtual routing table. In the same way a VLAN separate different LANs into virtual LANs and mac-address tables, a virtual routing table is its own separate routing table on a router. Only keeping one global routing table makes separating traffic difficult, especially in a large service provider network where customers most likely are using overlapping IP ranges. Separating the customers into their own virtual routing tables is a necessity.
In the network topology we have red CEs and blue CEs. Let's configure the RED VRF to start generating some VPNv4 routes!
set interfaces ge-0/0/1 vlan-tagging
set interfaces ge-0/0/1 unit 51 vlan-id 51
set interfaces ge-0/0/1 unit 51 family inet address 10.5.51.5/24
set interfaces ge-0/0/1 unit 61 vlan-id 61
set interfaces ge-0/0/1 unit 61 family inet address 10.5.61.5/24
set routing-instances RED instance-type vrf
set routing-instances RED interface ge-0/0/1.51
set routing-instances RED interface ge-0/0/1.61
set routing-instances RED route-distinguisher 10.0.0.5:1
set routing-instances RED vrf-target target:65000:1
set interfaces ge-0/0/1 vlan-tagging
set interfaces ge-0/0/1 unit 71 vlan-id 71
set interfaces ge-0/0/1 unit 71 family inet address 10.7.71.7/24
set routing-instances RED instance-type vrf
set routing-instances RED interface ge-0/0/1.71
set routing-instances RED route-distinguisher 10.0.0.7:1
set routing-instances RED vrf-target target:65000:1
vrf RED
address-family ipv4 unicast
import route-target
65000:1
!
export route-target
65000:1
!
interface GigabitEthernet0/0/0/1.61
vrf RED
ipv4 address 10.6.61.6 255.255.255.0
encapsulation dot1q 61
!
router bgp 65000
vrf RED
rd 10.0.0.6:1
address-family ipv4 unicast
label mode per-ce
redistribute connected
vrf RED
address-family ipv4 unicast
import route-target
65000:1
!
export route-target
65000:1
!
interface GigabitEthernet0/0/0/1.81
vrf RED
ipv4 address 10.8.81.8 255.255.255.0
encapsulation dot1q 81
!
router bgp 65000
vrf RED
rd 10.0.0.8:1
address-family ipv4 unicast
label mode per-ce
redistribute connected
Focusing on PE5, we first configure our CE-subinterfaces, one to CE51 and CE61 respectively, and tie them to the RED vrf. We also configure a route-distinguisher and route-target, both of which will be discussed shortly.
root@PE5> show route advertising-protocol bgp 10.0.0.11 table RED.inet.0 detail
RED.inet.0: 18 destinations, 37 routes (18 active, 0 holddown, 0 hidden)
* 10.5.51.0/24 (2 entries, 1 announced)
Route Distinguisher: 10.0.0.5:1
VPN Label: 299952
Nexthop: Self
Localpref: 100
AS path: [65000] I
Communities: target:65000:1
* 10.5.61.0/24 (2 entries, 1 announced)
Route Distinguisher: 10.0.0.5:1
VPN Label: 299984
Nexthop: Self
Localpref: 100
AS path: [65000] I
Communities: target:65000:1
root@PE5> show route table mpls.0
299952 *[VPN/170] 07:10:56
> to 10.5.51.51 via ge-0/0/1.51, Pop
299984 *[VPN/170] 07:01:33
> to 10.5.61.61 via ge-0/0/1.61, Pop
root@PE7> show route table RED.inet.0 detail active-path
RED.inet.0: 17 destinations, 45 routes (17 active, 0 holddown, 0 hidden)
10.5.51.0/24 (2 entries, 1 announced)
Route Distinguisher: 10.0.0.5:1
Next hop: 10.3.7.3 via ge-0/0/0.0, selected
Label operation: Push 299952, Push 299904(top)
Originator ID: 10.0.0.5
Communities: target:65000:1
VPN Label: 299952
10.5.61.0/24 (2 entries, 1 announced)
Route Distinguisher: 10.0.0.5:1
Next hop: 10.3.7.3 via ge-0/0/0.0, selected
Label operation: Push 299984, Push 299904(top)
Originator ID: 10.0.0.5
Communities: target:65000:1
VPN Label: 299984
The above output shows the VPNv4 routes advertised by PE5 and received by PE7. The routes contain the route-distinguisher and route-target we configured aswell as VPN labels generated by PE5 to identify each CE next-hop. The PE6 and PE8 routes have been edited out for brevity. Let's look at a traceroute from CE71 to CE51:
CE71#traceroute 10.5.51.51
1 10.7.71.7 8 msec
2 10.3.7.3 [AS 65000] [MPLS: Labels 299904/299952 Exp 0] 8 msec
3 10.1.3.1 [AS 65000] [MPLS: Labels 299776/299952 Exp 0] 16 msec
4 10.1.5.5 [AS 65000] [MPLS: Label 299952 Exp 0] 20 msec
5 10.5.51.51 [AS 65000] 8 msec
The traceroute show that the CE71 IP packet is sent to PE7 who pushes VPN label 299952 and transport label 299904. P3 swaps the 299904 transport label to 299776. P1 pops the transport label. PE5 pops the VPN label and forwards the IP packet to CE51.
We have now successfully built a MPLS L3VPN where the CEs can ping each other. The CE site prefixes have not yet been advertised though, let's fix this!
PE-CE BGP + CE Multihoming
Let's setup eBGP between PEs and CEs to advertise site prefixes while avoiding routing loops.
AS-override
All CEs will reside in AS 65001, the reason being that it's scalable and makes deploying new sites easier. However, by default eBGP will reject a prefix that has its own AS in the path. This means that a route advertised from CE51 will be rejected by CE71. To avoid this, we will configure as-override on our PE-routers, having them replace AS 65001 in the path with its own AS 65000, changing the received path on CE71 from "65001 65000" to "65000 65000", allowing CE71 to receive the prefix. The as-override happens when the PE advertises the route to the CE.
An alternative way of doing this is with the allowas-in 1 command on the CEs. However, a service provider cannot guarantee that it has control over the CE so we prefer the solution that can be configured in the PE only. Additionally, allowas-in requires the advertise-peer-as knob on the Junos PEs. Anyway, let's continue with the as-override configuration:
set routing-instances RED protocols bgp group CE51 peer-as 65001
set routing-instances RED protocols bgp group CE51 as-override
set routing-instances RED protocols bgp group CE51 neighbor 10.5.51.51
set routing-instances RED protocols bgp group CE71 peer-as 65001
set routing-instances RED protocols bgp group CE71 as-override
set routing-instances RED protocols bgp group CE71 neighbor 10.7.71.71
interface Loopback0
ip address 10.51.0.1 255.255.0.0
interface FastEthernet0/0.51
encapsulation dot1Q 51
ip address 10.5.51.51 255.255.255.0
router bgp 65001
bgp log-neighbor-changes
redistribute connected
neighbor 10.5.51.5 remote-as 65000
CE51#show ip bgp
Network Next Hop Path
*> 10.5.51.0/24 0.0.0.0 ?
*> 10.7.71.0/24 10.5.51.5 65000 i
*> 10.51.0.0/16 0.0.0.0 ?
*> 10.71.81.0/24 10.5.51.5 65000 65000 ? <-- as-override
interface FastEthernet0/0.71
encapsulation dot1Q 71
ip address 10.7.71.71 255.255.255.0
interface FastEthernet1/0
ip address 10.71.81.71 255.255.255.0
standby 1 ip 10.71.81.1
standby 1 priority 200
router bgp 65001
redistribute connected
neighbor 10.7.71.7 remote-as 65000
neighbor 10.71.81.81 remote-as 65001
CE71#show ip bgp
Network Next Hop Path
*> 10.5.51.0/24 10.7.71.7 65000 i
*> 10.7.71.0/24 0.0.0.0 ?
*> 10.51.0.0/16 10.7.71.7 65000 65000 ? <-- as-override
*> 10.71.81.0/24 0.0.0.0 ?
* i 10.71.81.81 i
Site-of-origin
CE71 and CE81 belong to the same site. If we allow routes from CE71 to be advertised back to CE81 then they might use the SP network as a transit and create a potential routing loop. We will therefore configure our PEs to add a site-of-origin community, allowing the PEs to filter routes to and from the CE71-CE81 site.
set policy-options community SOO_CE71 members origin:65000:7181
set policy-options policy-statement CE71_IN term SOO then community add SOO_CE71
set policy-options policy-statement CE71_OUT term SOO from community SOO_CE71
set policy-options policy-statement CE71_OUT term SOO then reject
set routing-instances RED protocols bgp group CE71 import CE71_IN
set routing-instances RED protocols bgp group CE71 export CE71_OUT
set routing-instances RED protocols bgp group CE71 peer-as 65001
set routing-instances RED protocols bgp group CE71 as-override
set routing-instances RED protocols bgp group CE71 neighbor 10.7.71.71
router bgp 65000
vrf RED
bgp unsafe-ebgp-policy
neighbor 10.8.81.81
remote-as 65001
address-family ipv4 unicast
as-override
site-of-origin 65000:7181
With this configuration in place, PE8 will not advertise routes from CE71 back to CE81; PE7 will not advertise routes from CE81 back to CE71.
Conclusion
We have now looked at how MPLS L3VPN is configured and how it operates with its RDs, RTs and VPN labels. To learn more, one can play around with different combinations of RDs and RTs to build widely different topologies, and we have not even covered the route-leaking topic yet. There is still much to explore. Until next time, thanks for reading!